home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / ietf / ripv2 / 92mar.min < prev    next >
Text File  |  1993-02-17  |  3KB  |  84 lines
  1. The Minutes below should be considered a Rough Draft - 4/01/92 Megan
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Gary Malkin
  7.  
  8. RIP-V2 Working Group Minutes
  9.  
  10. Status Update
  11.  
  12.  
  13.  
  14. Chairperson        Gary Scott Malkin / gmalkin@ftp.com
  15.  
  16. Mailing List        ietf-rip(-request)@ftp.com
  17.  
  18. Date of Last meeting    San Diego IETF / March 18, 1992
  19.  
  20. Date of next meeting    Boston IETF / July 1992
  21.  
  22. Progress        Settled on final packet format and new field
  23.             definitions.  Determined that no backwards
  24.             compatibility issues exist.  Made first pass
  25.             at listing the objects needed in the MIB.
  26.  
  27. Milestones:
  28.     Boston        Final review of RIP-II I-D and submission into
  29.             the standards track.  First review of RIP-II MIB.
  30.  
  31.     Washington    Review of implementations.  Final review of MIB.
  32.  
  33.     TBD        Given successful implementation experience,
  34.             advancement of RIP-II to Draft Standard.  Submission
  35.             of MIB into the standards track.
  36.  
  37.     TBD        Final meeting to achieve closure on any pending
  38.             issues.
  39.  
  40.  
  41.  
  42. Agenda
  43.  
  44.     o Review of Working Group charter
  45.  
  46.     o Review of newest draft document
  47.  
  48.     o Discussion of backwards compatibility issues
  49.  
  50.     o Discussion of security issues
  51.  
  52.     o What needs to go into the MIB
  53.  
  54.  
  55. The charter was accepted unchanged.
  56.  
  57. There were two changes to the packet format do to some confusion about
  58. the Routing Domain field.   The RD field, as defined, is a per packet,
  59. user configurable parameter.  It has, therefore, been moved into the
  60. Must Be Zero field in the RIP packet header.  The RD field which was in
  61. the RIP entry has been renamed to the Route Tag.  It is used to indicate
  62. that the route was learned from an external source.  The exact use of this
  63. field is still under discussion; however, it has been determined that
  64. the contents of the RT field must be preserved when that route is
  65. propagated.
  66.  
  67. The subsumption of routes, made necessary by the addition of the subnet
  68. masks is still under work.  The issues accompanying supernetting were
  69. also discussed, but no final solutions were reached.  We did determine
  70. that there should be no user controls for this, since this could lead
  71. to black holes if routers were dis-similarly configured.  It was decided
  72. that supernetting could not be used in the presence of RIP-I routers.
  73.  
  74. It should be explicitly mentioned that next hop is an advisory value.
  75. Next hop may also only be used for the directly connected network
  76. over which it was received.
  77.  
  78. It was decided that addressless links would not be considered.
  79.  
  80. We will need a new route type for MIB-II.
  81.  
  82. It should be mentioned, if RFC 1058 does not, that split horizon
  83. does not apply to routes learned via routing protocols other than RIP.
  84.